[レポート] Amazon DocumentDB for expert practitioners #DAT417-R #AWSreInvent

コーヒーが好きな emi です。

AWS re:Invent 2024 で chalk talk 「Amazon DocumentDB for expert practitioners」に参加しました。

本セッションでは、DocumentDB パフォーマンスの最適化について焦点が当てられました。
主なポイントとして、ドキュメントサイズの重要性が挙げられ、4.5KB という大きなドキュメントは Read IOPS が高くなり、キャッシュ効率が低下します。

既存のワークロードでは 2KB のドキュメントでデータの10%をキャッシュできたが、4.5kのドキュメントでは4%しかキャッシュできず、リードIOPSは3600になりました。
改善策としては、より小さな文書サイズを使用し、圧縮を有効にすることで、メモリ要件を減らし、キャッシュヒット率を向上させることができます。
このセッションでは、パフォーマンスを最適化するために、読み取りIOPSとキャッシュヒット率を監視することの重要性も強調されました。

概要

タイトル：DAT417-R | Amazon DocumentDB for expert practitioners [REPEAT]
DocumentDB（MongoDBとの互換性あり）は、ネイティブ・ドキュメント・データモデル・エンタープライズ・ワークロードのためのフルマネージド・データベース・サービスとして、データベースを運用するための未分化な重労働を取り除き、顧客へ価値を提供することに時間を集中できるようにします。このチョークトークでは、さまざまなワークロードに対する圧縮、パフォーマンス、コストなどの実装トレードオフについて深く掘り下げます。エラスティック・クラスタやその他の主要機能を使用して、スケーラブルなAmazon DocumentDBベースのソリューションを構築する方法を学びます。

スピーカー
Cody Allen（Pr. DocumentDB Specialist SA, AWS）
Douglas Bonser（Sr. Specialist Solution Architect, AWS）

Mon, December 2
10:00 AM - 11:00 AM PST
Mandalay Bay | Level 2 South | Reef C

Session types: Chalk talk
Topic: Databases
Area of interest: Well-Architected Framework
Level: 400 – Expert
Role: Developer / Engineer, IT Professional / Technical Manager, Solution / Systems Architect
Services: Amazon DocumentDB (with MongoDB compatibility)

レポート

模擬顧客セッションのような形で始まりました。
現在はこんなワークロードで動かしていて、こんな問題が起こった、さあ何を改善していこうか、といった具合です。

現行ワークロードの特性

• 1億件のドキュメント（100MM documents）、各ドキュメントサイズは2KB。
• 合計データサイズは約200GiB、インデックスサイズは7.6GiB。
• 作業セット（Working Set）は全データの10%であり、約21GiBのキャッシュメモリ（r6g.xlargeインスタンス）に収まる。

「Working set is 10% of data」と書かれていました。作業セットという領域は、頻繁にアクセスされるデータの集合で、今回のケースでは全体の 10% が作業セットになっているということです。

• 作業セット（Working Set）がキャッシュサイズに収まる場合、読み取り操作はキャッシュから効率的に提供される。
• キャッシュを有効活用することで、DocumentDBのパフォーマンスを最大化できる。

パフォーマンスの前提

頻繁にアクセスされるデータはキャッシュに収まり、読み取り操作は主にキャッシュから処理されるため、高速化が期待できる。

新しいワークロードの課題

新しいワークロードのリード操作がキャッシュで処理されるはずですが、実際には 3600 Read IOPS を消費しています。

• ドキュメントサイズが4.5KBに増加し、インデックスサイズも10.3GiBに増加。
• 作業セットが全データの4%に縮小。
• キャッシュ可能なデータが4%程度となり、想定以上にディスクアクセスが発生（3600リードIOPS）。

推奨される改善策

• ドキュメントサイズを縮小
  • 小さいドキュメントサイズ（例: 2KB）を維持することで、効率的なキャッシュ利用が可能。

ドキュメントサイズが小さいほど多くのデータを保存可能。
ドキュメントサイズが大きい場合、1ページに収容できるドキュメント数が減少し、結果として保存可能なドキュメント数が制限されます。

• 圧縮を有効化
  • ドキュメントを圧縮することでキャッシュヒット率を向上させ、メモリ使用効率を改善。
• 統計の監視
  • キャッシュヒット率やリードIOPSを監視し、作業セットのサイズを把握する。

キャッシュ設計の重要性

• キャッシュはインスタンスのRAMの2/3を利用可能であり、残りはDocumentDBエンジンの動作に確保される。
• ページサイズ（8KB）を考慮し、ドキュメントサイズとキャッシュ効率のバランスを取ることが重要。

Key Takeaways（主要なポイント）

• ドキュメントサイズ ≠ ディスク上のサイズ
  • ドキュメントサイズがそのままディスク上のサイズになるわけではない。8KBページ単位で保存されるため、書き込み時に「サイズの増幅（Write Amplification）」が発生。
• 8KBページ単位で管理
  • DocumentDBはドキュメントごとではなく、8KBページ単位でデータを管理。
• ドキュメントサイズの影響
  • ドキュメントが大きいほど、パフォーマンスに悪影響を及ぼす可能性が高い。
• コレクションレベルでの圧縮
  • 圧縮を有効化することで、ストレージ使用量とキャッシュ効率を改善可能。

What can I do about this?（対策案）

• db.stats() を活用
  • ドキュメントの平均サイズを特定し、最適化の方向性を決定する。
• リードIOPSの確認
  • ReadIOPSをモニタリングし、不要なディスクI/Oを検出。
• キャッシュヒット率の確認
  • BufferCacheHitRatio と IndexBufferCacheHitRatio をチェックし、キャッシュの効果を評価。
• 圧縮の有効化
  • データの圧縮を適用し、キャッシュ効率とストレージ使用量を向上。

バーコードで読み込めた圧縮ツールです。
https://github.com/awslabs/amazon-documentdb-tools/tree/master/performance/compression-review

終わりに

re:Invent 1 日目、12/2 の朝 10:00 からの Mandalay Bay でのセッションで、最初に「Is your first session at reinvent 2024?」と聞かれ、多くの人が手をあげました。「リピートがあるのでまた来てくれ！新しいジョークを用意して待っている！」と会場を笑わせてくれました。
DocumentDB のパフォーマンス改善について深堀りするセッションで、私にはかなり難しかったです。
会場の方はかなり発言されていて、議論が盛り上がっていました。